<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>
<head>
<title>Eclipse Platform/Core</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<link rel="stylesheet" href="http://dev.eclipse.org/default_style.css" type="text/css">
</head>
<body>
<center>
	<font class=indextop>core</font><br>
	<font class=indexsub>the foundation of the platform</font><p></p>
	<a href="../../main.html">[home]</a>
	<a href="../../documents.html">[documents]</a>
	<a href="../../downloads.html">[downloads]</a>
	<a href="../../resources.html">[resources]</a>
	<a href="../../planning.html">[planning]</a>
	<a href="../../testing.html">[testing]</a>
</center>
<br>
<table BORDER=0 CELLPADDING=2 WIDTH="100%" >
  <tr> 
    <td ALIGN=LEFT VALIGN=TOP COLSPAN="2" BGCOLOR="#0080C0"><b><font face="Arial,Helvetica" color="#FFFFFF">Planning</font></b></td>
  </tr>
  <tr> 
    <td ALIGN=RIGHT VALIGN=TOP WIDTH="2%"><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
    <td><b>Theme: Built to Last</b> <p><em>Platform/Runtime</em></p>
      <ul>
        <li><img src="../../images/small_progress.gif" width="14" height="5"> 
          <em>(Performance)</em> Improvements on Registry Structure - Investigate 
          ways of making it smaller and more scalable. Consider radical changes. 
          Think outside the box.</li>
        <li> <em>(Performance)</em> Resource Bundles Implementation - Both speed 
          and space. Look at array bundles. More efficient NL tooling. (cross 
          team - Platform/Runtime, JDT/UI)</li>
        <li><em>(Performance)</em> Runtime Bundles - Flush the state structure. 
          Reduce the memory footprint of the running framework by streaming the 
          state on startup and not keeping the state in memory.</li>
        <li><em>(Outreach)</em> Help people write dynamic code 
          <ul>
            <li>all bundles in the RCP should be completely dynamic aware and 
              dynamic enabled (all teams)</li>
            <li> enable dynamic awareness for addition in all plug-ins (all teams)</li>
          </ul>
        </li>
        <li> <em>(Outreach)</em> Correct use of new runtime APIs: preferences, 
          jobs, encoding/content type, OSGi services (identify use cases) (all 
          teams)</li>
        <li>JXE adaptor</li>
        <li>Reduce class-library dependencies - Investigate having bundles included 
          in the RCP be able to compile and run against 1.3 class libraries.</li>
        <li>OSGi spec work: 
          <ul>
            <li>working on OSGi specs </li>
            <li>finish PlatformAdmin APIs for installing/uninstalling/updating 
              bundles</li>
            <li>introduce support for batched bundle events (thus making batched 
              registry change events viable)</li>
            <li>framework layering</li>
            <li>API changes</li>
          </ul>
        </li>
        <li>Implementing OSGi R4 - A new version of the OSGi spec will be released 
          soon and the OSGi code must be updated to conform to any changes.</li>
        <li>Running on another OSGi implementation (probably will be deferred)</li>
        <li>OSGi test suite integration - OSGi includes a group of test suites 
          for compliance. We should integrate these tests with out automated suites 
          to be run against builds.</li>
        <li>Dynamic Support - Inclusion of OSGi into the runtime has given Eclipse 
          the ability for dynamic bundles. We need to expand the infrastructure 
          for supporting dynamic awareness and enablement. Investigate the use 
          of OAF. (OSGi Application Framework)</li>
        <li>evaluate the need of special support to allow automatic/product-driven/user-driven 
          integration of non-plug-in code into Eclipse - need to investigate community 
          needs, current workarounds, and carefully understand possible drawbacks. 
          Use cases: providers of standard APIs (such as JDBC, JNDI, etc) (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=3074">bug 
          3074</a>)</li>
        <li>Programatically add registry entries - Currently the only way that 
          items are added to the extension registry is via files and parsing. 
          We need to investigate whether or not there is a need for being able 
          to programatically add items to the registry. One problem to consider 
          is persistence.</li>
        <li>Split up Runtime - The org.eclipse.core.runtime plug-in contains a 
          lot of disjoint functionality and can possibly be split up into separable 
          components along the lines of the extension registry, preferences, job 
          manager, content type, etc.</li>
        <li><img src="../../images/small_x.gif" width="10" height="12"> <em>(Deferred)</em> 
          Rolling Log File - The Eclipse log file is ever-increasing and could 
          be changed to roll and stay at a managable size. Note that this might 
          be deferred since users are able to delete/manage the log file via the 
          PDE Error Log View.</li>
        <li>Stub Plug-ins - Investigate shipping plug-ins which have only the 
          plugin.xml and code/resources are downloaded as you need them.</li>
        <li>Content types - For 3.0 we created new content type APIs. We need 
          to fill in the implementation and then ensure that people are taking 
          advantage of it. (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=67884">bug 
          67884</a>)</li>
        <li><img src="../../images/small_check.gif" width="10" height="11"> Path 
          issues: There are some user problems coming up where they have already 
          existing directory structures on disk and they would like to create 
          these project within Eclipse but we don't allow them because their path 
          names contain &quot;illegal&quot; characters such as slashes and colons.(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=24152">bug 
          24152</a>) <a href="../documents/path_changes.html">See proposed solution</a>.</li>
      </ul>
      <p><em>PDE/Build</em></p>
      <ul>
        <li>Build RPMs for Linux - The build support should be able to build RPMs 
          for Linux since this is one standard that Linux system use for installation.</li>
        <li>PDE/Build test suites - We should be able to create automated test 
          suites for a lot of the functionality in the PDE/Build component.</li>
        <li>Adapt to OSGi R4 changes - Since a new version of the OSGi spec will 
          be available, we need to react to the changes.</li>
      </ul>
      <p><em>Platform/Resources</em></p>
      <ul>
        <li><img src="../../images/small_progress.gif" width="14" height="5"> 
          Improve IndexedStore 
          <ul>
            <li><img src="../../images/small_x.gif" width="10" height="12"> <em>(Deferred)</em> 
              Cloudscape is a Java database implementation that has been donated 
              to Apache by IBM. We should investigate making it an Eclipse plug-in 
              and then using it for implementation of the IndexedStore. (which 
              is the backing store for persistent properties and the history store)</li>
            <li><img src="../../images/small_progress.gif" width="14" height="5"> 
              Investigate other alternatives for the history/property store implementation. 
            </li>
          </ul>
        </li>
        <li><img src="../../images/small_check.gif" width="10" height="11"> Better 
          story for external tool builders - There are bugs when people have multiple 
          external tool builders on the same project. Namely, we have been using 
          the builder-id as a unique way to identify the builder, but since the 
          external tool builder is a wrapper for the script that is really doing 
          the work, the id is not unique across the scripts. Fixing this problem 
          will require a change in the workspace tree file format. (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=21029">bug 
          21029</a>)</li>
        <li>Allow merge for Copy/Move - Current implementation of copy/move requires 
          that the destination resource/path does not exist. We should investigate 
          allowing merge in the workspace tree. This would benefit refactoring 
          actions. (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=31883">bug 
          31883</a>, <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=29838">bug 
          29838</a>)</li>
        <li><img src="../../images/small_check.gif" width="10" height="11"> APIs 
          for maintaining file permissions - There are currently bugs related 
          to copying/moving resources on Linux machines and the file permissions 
          are not retained. This is especially apparent in the case where we end 
          up doing a copy/move by transferring stream data rather than a file-system 
          level copy/move (for instance across volumes) and when we restore file 
          contents from local history. In these cases the file permissions are 
          not retained. This bug is a candidate for deferral as it can be argued 
          that support should be in java.io.File. (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=20575">bug 
          20575</a>, <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=26100">bug 
          26100</a>)</li>
        <li>Share metadata in the repository - In Eclipse 3.0 we enabled project 
          preferences which allows the sharing of project-level user settings. 
          We need to investigate taking this support further...for instance in 
          sharing markers, persistent properties, and other resource metadata. 
          (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=21411">bug 21411</a>, 
          <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=26809">bug 26809</a>)</li>
        <li>Improve Debugging Information - We need to improve some of the debugging 
          information in the Resources plug-in. One thing which people have been 
          asking for is a way to find out &quot;who triggered the build?&quot;.</li>
        <li><em>(Performance)</em> Fix ResourcesPlugin#startup code - The Resources 
          plug-in agressively tries to load the workspace during its startup but 
          that is not only unnecessary but also undesirable.</li>
        <li>File encodings - For 3.0 we created new file encoding APIs to allow 
          for encoding changes to be visible in resource deltas. We need to fill 
          in this implementation. There are also new APIs for content type changes 
          at the Runtime level. We need to react to these changes and reflect 
          them in resource deltas. Note that there will be down-stream changes 
          for other teams to adapt to. (JDT/Core for instance) (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=59899">bug 
          59899</a>)</li>
        <li>Project natures could give hints about the content type for files. 
          (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=69640">bug 69640</a>)</li>
        <li><img src="../../images/small_check.gif" width="10" height="11"> Convert 
          our existing performance tests to take advantage of the new performance 
          framework provided by RelEng.</li>
        <li>Support overriding string values from properties files. Basically, 
          if a plugin defines a string in plugin.properties or in a java resource 
          file, someone should be able to provide alternate values for some strings. 
          (request from Platform/Update)</li>
      </ul>
      <p>&nbsp;</p></td>
  </tr>
  <tr> 
    <td ALIGN=RIGHT VALIGN=TOP WIDTH="2%"><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
    <td><p><b>Theme: Rich Client Platform (RCP)</b> </p>
      <p><em>Platform/Runtime</em></p>
      <ul>
        <li>End-to-End Development Story (cross team)</li>
        <li>End-to-End Application Story (installation, running, configuration, 
          updating, etc) (cross team)</li>
        <li>JNLP/WebStart (Java Network Launch Protocol) (cross team - Platform/Runtime, 
          Platform/Update)</li>
        <li>Examples - In Eclipse 3.0 we laid the foundation for a Rich Client 
          Platform. Now people are interested in it and want to use it and the 
          best way to educate them is to write example of our own that we can 
          make available. (all teams)</li>
        <li>Add support for framework extensions.</li>
      </ul>
      <p><em>PDE/Build</em></p>
      <ul>
        <li>JXE support - supporting framework for building JXEs</li>
      </ul>
      <p><em>Platform/Resources</em></p>
      <ul>
        <li>Allow markers for non-resources or move markers to own plug-in? (org.eclipse.core.runtime.markers) 
          Need to investigate and list use cases.</li>
      </ul>
      <p>&nbsp;</p></td>
  </tr>
  <tr> 
    <td ALIGN=RIGHT VALIGN=TOP WIDTH="2%"><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
    <td><b>Theme: Large-scale Development</b> <p><em>PDE/Build</em></p>
      <ul>
        <li>PDE support for exporting to an update site (updating the site.xml)</li>
        <li>Building against an update site - Currently we require all resources 
          to be local when building. We need to investigate being able to build 
          against JARs, etc which exist on update sites.</li>
      </ul>
      <p><em>Platform/Resources</em></p>
      <ul>
        <li>Logical vs Physical - IResource on the physical side -&gt; create 
          new logical layer and create a mapping (too many people already relying 
          on IResource as is) (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=37723">bug 
          37723</a>) (cross team - Platform/Resources, Platform/Team)</li>
        <li>Improve team control over resource operations - Investigate to see 
          if we still need to add more control over other opertions. Essentially 
          expanding the move/delete hook to include creation, etc. (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=37722">bug 
          37722</a>) (cross team - Platform/Resources, Platform/Team)</li>
        <li>Remote workspace and remote resources - Investigate dealing with remote 
          workspaces and remote resources. (similar to support that was in Eclipse 
          0.5 where we had synchronizing on resource existance rather than content 
          and we would retrieve the contents when necessary)</li>
      </ul>
      <p></p></td>
  </tr>
  <tr> 
    <td ALIGN=RIGHT VALIGN=TOP><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
    <td><p><strong>Theme: Broaden the Community</strong></p>
      <p><em>Platform/Runtime</em></p>
      <ul>
        <li>Real RCP web presence, book, articles (all teams)</li>
      </ul>
      <p>&nbsp;</p></td>
  </tr>
  <tr>
    <td ALIGN=RIGHT VALIGN=TOP><img SRC="../../images/Adarrow.gif" BORDER=0 height=16 width=16></td>
    <td><p><strong>Other Components</strong></p>
      <p>While coming up with our component plan, here are some potential issues/plan 
        items that we have identified in other components.</p>
      <p><em>Platform/Update</em></p>
      <ul>
        <li> Better support for creating/managing internal mirrors</li>
        <li> More widespread use of Update - We should use the update manager 
          to get milestone builds, etc. Use the technology we build!</li>
        <li>Create an Eclipse Installer - We should be able to download a minimal 
          application which uses update site + checkboxes to install what you 
          want.</li>
        <li>Adapt to OSGi R4 changes - Since a new version of the OSGi spec will 
          be available, we need to react to the changes. </li>
      </ul>
      <p><em>PDE/UI</em> </p>
      <ul>
        <li>Wizards for RCP - Part of the end-to-end RCP story. We should have 
          wizards for creating RCP applications, targeting an RCP platform, etc.</li>
        <li>PDE to manage target manifests and make launching more efficient (incrementally 
          generate/maintain the manifests rather than relying on the runtime to 
          generate them on every launch). This improves performance and accuracy. 
          No more need for -clean.</li>
        <li>Improve Bundle Tooling - We need to improve the manifest editor, etc.</li>
        <li>feature request: File -&gt; Export -&gt; Into my currently running 
          dev (Java doits!)</li>
        <li>Adapt to OSGi R4 changes - Since a new version of the OSGi spec will 
          be available, we need to react to the changes.</li>
        <li>Targetting JAR'd plug-ins - In Eclipse 3.0 we have the ability to 
          run against (and update) plug-ins which are shipped as JAR files. We 
          need to expand this support so they can be included in the target platform 
          as well.<br>
        </li>
      </ul></td>
  </tr>
</table>


</body>
</html>